1. Field of the Invention
The present invention relates to a computer system, and deals more particularly with a method, system, and computer program product for using device certificates to authenticate servers before automatic address assignment thereto.
2. Description of the Related Art
In client-server networking environments, a device functioning as a client generally seeks to locate a device functioning as a server in order to access data (such as a Web page, a traditional flat file, etc.) or perform transactions with application programs executing on the server. Neither clients nor servers typically attempt to locate other clientsxe2x80x94that is, communications are usually established by the client and not by the server. The client typically locates a server that can perform the desired service by issuing a get_host_by_name( ) function call (or equivalent) using a known host name (such as an Internet Protocol, or IP, name), in order to resolve this server host name to a server address (such as an IP address). The get_host_by_name( ) function call causes a query to be issued to a Domain Name System (DNS) service. A DNS server maintains a stored mapping of host names to IP addresses. Upon receiving a query for a particular host name, the DNS server can then return the stored IP address mapped to (i.e. associated with) that host name. These stored mappings are typically statically administered, and therefore it is typically important for a particular host name to have a constant IP address in order to facilitate dynamic access to that host (i.e. server) in a predictable manner that is independent of factors such as the timing of issuing the get_host_by_name( ) call. Traditionally, enabling use of a constant IP address is achieved by statically configuring the server""s IP address at the server itself and at the DNS.
Client and server devices tend to attach to a network dynamically, and remain attached for varying lengths of time. Each such device must obtain a network address (such as an IP address), if it has not already been configured with one, in order to participate in network communications. In local area network (LAN) configurations, it is common practice to dynamically assign an IP address to a device when it connects to the LAN (for instance, when the device powers on). Protocols such as the Bootstrap Protocol (also known as xe2x80x9cBootPxe2x80x9d) and the Dynamic Host Configuration Protocol (commonly known as xe2x80x9cDHCPxe2x80x9d) are often used, among other purposes, to enable automatic dynamic assignment of an IP address to an IP host. (xe2x80x9cHostxe2x80x9d in this context merely refers to a computer device that has the capability of communicating with other computers.) A host requesting an IP address using DHCP is referred to as a xe2x80x9cDHCP clientxe2x80x9d, and the host which implements the DHCP service and responds to such requests is referred to as a xe2x80x9cDHCP serverxe2x80x9d. Similarly, in the BootP protocol the hosts are referred to as xe2x80x9cBootP clientsxe2x80x9d and xe2x80x9cBootP serversxe2x80x9d. The policies and techniques with which the BootP and DHCP protocol implementations manage the assignment of IP addresses to hosts generally differ depending on whether the host is a client or a server. As described above, server addresses are typically statically configured, and constant in value. Thus, the benefits of BootP and DHCP for automatic IP address generation and configuration are therefore not generally available for hosts whose primary function is as a server. Instead, the server""s address must be entered into the server manually, and if the server changes to a different physical location then a different address must be entered. (BootP is defined in the Internet Engineering Task Force""s Request for Comments (RFC) 951, titled xe2x80x9cBOOTSTRAP Protocol (BootP)xe2x80x9d, and DHCP is defined in RFC 1541, titled xe2x80x9cDynamic Host Configuration Protocolxe2x80x9d.)
In view of the advantages of using BootP and DHCP, it would be desirable to enable use of these protocols for servers. Currently, if the physical topology of a LAN is changed, IP addresses of servers previously connected to segments of the changed topology may be no longer valid, and routers will then be unable to route traffic to those invalid addresses. The IP addresses of affected servers must first be changed in the DNS mapping, concurrently with reconfiguring each such server to use its new address. Typically, the reconfiguration of the server is a manual process, and the DNS update may sometimes be a manual process as well. If BootP or DHCP were available for dynamic address assignment to a server when a topology change occurred, this would enable significant improvements in the ability to centrally manage an IP network. For example, the BootP or DHCP service could dynamically manage which IP addresses are associated with segments of the physical network, without needing to closely synchronize this activity with the physical location of computers acting in a server role, and without requiring these computers to be reconfigured concurrently with changes to the physical topology. The need for such improvements is compounded by the fact that enterprises (that is, large-scale computing installations and/or computing networks) are moving away from a centralized computing model to a highly distributed model of application deployment. As this move towards distributed computing progresses, more and more systems in the corporate network will take on the capability of performing in a server role. In the absence of automated IP address generation and management (such as that provided by BootP and DHCP), extra effort will be required to administer and manage the IP addresses for this increasing number of servers.
It would be advantageous to dynamically and automatically assign (e.g. using BootP or DHCP) an IP address to a host acting in a server role, such that the server""s IP address would reflect the current IP address definition associated with its host name in the DNS hostname-to-address mapping. Some implementations of this technique are already in practice. However, these known techniques are deficient because of their inability for the network management component to know for sure what device is requesting an IP address assignment. These techniques do not have the capability of preventing a malicious third party from attaching to the network and masquerading as a host that is currently off-line (and is therefore not using its assigned IP address). This deficiency leaves such implementations vulnerable to the masquerading attack. Exploring this scenario in more detail, it would be possible for a malicious individual to program a different computer to simulate the functions of the host under attack, and then to cause a loss of power or a network disconnection such that the original host becomes disconnected or fails, and finally to enable the new (attacking) host to contact a BootP or DHCP server and impersonate the original host. Once an attacking host obtains the DNS identity of the original host by substituting its own IP address into the DNS mapping for the original host""s name, the attacking host is then in a position to perform any number of security attacks (such as a Trojan horse attack, a denial-of-service attack, passing programs containing viruses or other harmful software to users, etc.). Or, the masquerading host could attempt to steal secrets (such as user identification, passwords, and/or private personal data) from users who log on to the masquerading host believing it to be the original host.
Given the current state of the art, it is also easy for an attacker to set up a fake DHCP service (or, similarly, a fake BootP service)xe2x80x94that is, one where the masquerading host assumes the responsibility for, inter alia, assigning IP addressesxe2x80x94thereby opening up an array of additional attacks by which the attacker actually assumes the identity of its victim server host, while the victim is still running. Current art does not provide any way for a DHCP server, before assigning an IP address, to distinguish an authentic requesting host from an attacker. Nor does it provide a means for a requesting host (i.e. a DHCP client) to know that the DHCP server from which it requests an IP address is a true source of valid configuration information. While there have been some suggestions of ways a DHCP server could authenticate a requesting host, such as via a user identification and password transmitted in a HyperText Transfer Protocol (HTTP) flowxe2x80x94which might be protected from third-party tampering using a secure communications exchange such as that provided by the Secure Sockets Layer (SSL) protocolxe2x80x94heretofore all known proposals have involved some kind of authentication occurring above the physical device level.
Accordingly, what is needed is a technique with which the above-described inadequacies in the current art can be overcome.
An object of the present invention is to provide a technique for enabling devices functioning as servers in a network to participate in automatic address assignment mechanisms.
Another object of the present invention is to provide this technique in a manner that enables the server requesting an automatically assigned address to be authenticated before assigning an address thereto.
Yet another object of the present invention is to provide this technique whereby the source of an automatically assigned address can be authenticated before the address is used by a server.
Still another object of the present invention is to provide this technique using authentication between pairs of devices at the physical level.
A further object of the present invention is to provide this technique by using a digital certificate and a public/private key pair for a device, where the device is uniquely identified by a device identifier stored in the certificate.
Other objects and advantages of the present invention will be set forth in part in the description and in the drawings which follow and, in part, will be obvious from the description or may be learned by practice of the invention.
To achieve the foregoing objects, and in accordance with the purpose of the invention as broadly described herein, one embodiment of the present invention provides a method, system, and computer program product for using device certificates to authenticate servers before assignment of addresses. In one embodiment, this technique comprises: creating a public key, private key pair for a particular device that will function as a server device, this key pair adapted for use in public key cryptography systems; creating a first device certificate for the server device, wherein the first device certificate identifies the server device using a device identifier associated with a network adapter card directly attached to the server device; storing the public key in the first device certificate; securely storing the private key on the server device; sending an address assignment request from the server device to an address assignment service; receiving the address assignment request at the address assignment service; authenticating, by the address assignment service, the server device; assigning an address to the server device if the authentication determines that the server device is authentic; returning an address assignment response, comprising the assigned address, from the address assignment service to the server device if the authentication determines that the server device is authentic; and receiving the returned address assignment response at the server device.
Sending the address assignment request may further comprise: digitally signing, by the server device, one or more fields of the address assignment request wherein the one or more fields includes at least the address identifying the server device, using the private key and resulting in creation of a first digital signature; and sending, along with the address assignment request, the first digital signature and the first device certificate. Receiving the address assignment request may further comprise receiving the first digital signature and the first device certificate, in addition to the address assignment request. Authenticating the server device may further comprise: decrypting the received first digital signature using the public key stored in the first device certificate; obtaining a certificate authority (CA) public key associated with a CA which created a second digital signature stored in the first device certificate; decrypting the second digital signature using the obtained CA public key; concluding that the first device certificate is authentic if the decrypted second digital signature is authentic; and concluding that the server device is authentic if (1) the decrypted first digital signature is authentic, (2) a device identifier value represented by the decrypted first digital signature matches the address associated with the network adapter card of the server device, and (3) the first device certificate is authentic.
Sending the address assignment request, the first digital signature, and the first device certificate may also send a CA certificate containing the CA public key to the address assignment service using a copy of the CA certificate stored at the server device. In this case, obtaining the CA public key uses this sent CA certificate.
In one aspect, assigning the address may further comprise digitally signing, by the address assignment service, one or more fields of the address assignment response wherein the one or more fields includes at least the assigned address, using a second private key associated with the address assignment service and resulting in creation of a third digital signature. Returning the address assignment response may further comprise returning, along with the assigned address: (1) a second device certificate, wherein the second device certificate comprises (a) an address assignment service identifier associated with an address assignment service adapter card of a second server device performing the address assignment service, and (b) a second public key, the second public key associated with the second private key and adapted for use in public key cryptography systems, and (2) the third digital signature. Receiving the returned address assignment response at the server device may also receive the second device certificate and the third digital signature. The technique may then further comprise: decrypting, by the server device, the received third digital signature using the second public key stored in the received second device certificate; obtaining, by the server device, a second CA public key associated with a second CA which created a fourth digital signature stored in the second device certificate; decrypting, by the server device, the fourth digital signature using the obtained second CA public key; concluding that the second device certificate is authentic if the decrypted fourth digital signature is authentic; concluding that the address assignment service is authentic if (1) the decrypted third digital signature is authentic, (2) a second device identifier value represented by the decrypted third digital signature matches the address assignment service identifier, and (3) the second device certificate is authentic; and using the received address at the server device only if the address assignment service is authentic.
The technique may further comprise updating a Domain Name System (DNS) service mapping for at least one of (1) a host name, (2) a medium access control (MAC) address, or (3) a DNS-resident device identifier that is associated with the server device and is included in the address assignment request, wherein the update of the mapping reflects the assigned address. In this case, the technique may further comprise: digitally signing an update request by the address assignment service using the second private key, resulting in creation of a fifth digital signature, wherein the update request specifies the host name and the assigned address; sending the fifth digital signature, the update request, and the second device certificate to the DNS service; receiving the fifth digital signature, the update request, and the second device certificate at the DNS service; decrypting, by the DNS service, the received fifth digital signature using the second public key stored in the received second device certificate; obtaining, by the DNS service, the second CA public key; decrypting, by the DNS service, the fourth digital signature using the obtained second CA public key; concluding, by the DNS service, that the second device certificate is authentic if the decrypted fourth digital signature is authentic; concluding, by the DNS service, that the address assignment service is authentic if (1) the decrypted fifth digital signature is authentic, (2) the second device identifier value represented by the decrypted fifth digital signature matches the address assignment service address physically associated with the address assignment service adapter card of the second server device performing the address assignment service, and (3) the DNS service concludes that the second device certificate is authentic; and performing the update of the mapping only if the DNS service concludes that the address assignment service is authentic. This technique may also further comprise: returning a message from the DNS service to the address assignment service, the message indicating whether the update of the mapping was successfully performed; and wherein assigning the address to the server device operates only if the message indicates a successful update.
The second device certificate may further comprises a capability indicator indicating whether the address assignment service is authorized to assign addresses. In this case, the received address is not used if the capability indicator is not properly set.
Returning the assigned address, the second device certificate, and the third digital signature may also return a second CA certificate containing the second CA public key to the server device using an address assignment service copy of the second CA certificate. In this case, obtaining the second CA public key uses the returned CA certificate.
The technique of this aspect may further comprise: creating a handshaking message by the server device, wherein the handshaking message comprises one or more message fields and a sixth digital signature, wherein the one or more message fields include a time stamp, the sixth digital signature computed over the one or more message fields; sending the handshaking message from the server device to the address assignment service; receiving the handshaking message at the address assignment service; decrypting the sixth digital signature using the public key of the server device; and completing an address assignment process initiated by the address assignment request if the decrypted sixth digital signature is valid and the time stamp is not stale.
The address assignment service may be a Bootstrap Protocol (BootP) service operating at a BootP server. Or, it might be a Dynamic Host Configuration Protocol (DHCP) service operating at a DHCP server.
Securely storing the private key may store the private key in a write-only memory of the server device, the write-only memory having an ability to perform computations using data values previously stored therein. Or, it might store the private key in a read-write memory of the server device, the read-write memory being readable only by means of a shared secret key.
The address identifying the server device in the first device certificate may be a medium access control (MAC) address of the network adapter card.
The technique may further comprise: generating, by the server device, a first challenge; including, by the server device, this first challenge in the one or more fields of the address assignment request; and including, by the address assignment service, the first challenge in the one or more fields of the address assignment response. In this case, using the received address further comprises using the received address only if the signed first challenge is valid.
Or, the technique may further comprise: generating, by the server device, a first challenge; including, by the server device, this first challenge in the one or more fields of the X address assignment request; generating, by the address assignment service, a second challenge; including the first challenge and the second challenge in the one or more fields of the address assignment response; and including, by the server device, the second challenge in the one or more message fields of the handshaking message. In this case, the received address further comprises using the received address only if the signed first challenge is valid, and completing the address assignment process further comprises completing the address assignment process only if the signed second challenge is valid.
In another embodiment, this technique may comprise: creating a public key, private key pair for a device that will function as a server device, this key pair adapted for use in public key cryptography systems; creating a device certificate for the server device, wherein the device certificate identifies the server device using a device identifier associated with a network adapter card directly attached to the server device; storing the public key in the device certificate; securely storing the private key on the device; sending an address retrieval request from a client device to the server device; receiving the address retrieval request at the server device; retrieving, by the server device, an address corresponding to the address retrieval request; returning the retrieved address to the client device; receiving the returned address at the client device; authenticating the server device; and using the received address if the authentication determines that the server device is authentic.
Returning the retrieved address may further comprise: digitally signing, by the server device, one or more fields wherein the one or more fields includes at least the retrieved address, using the private key, resulting in creation of a first digital signature; and returning, along with the retrieved address: (1) the device certificate and (2) the first digital signature. Receiving the returned address at the client device may also receive the device certificate and the first digital signature. Authenticating may further comprise: decrypting, by the client device, the received first digital signature using the public key stored in the received device certificate; obtaining, by the client device, a certificate authority (CA) public key associated with a CA which created a second digital signature stored in the device certificate; decrypting, by the client device, the second digital signature using the obtained CA public key; concluding that the device certificate is authentic if the decrypted second digital signature is authentic; and concluding that the server device is authentic if (1) the decrypted first digital signature is authentic, (2) a device identifier value represented by the decrypted first digital signature matches the server device address, and (3) the device certificate is authentic.
The server device may be executing a DHCP service. Or, the server device might be executing a DNS service.
The present invention will now be described with reference to the following drawings, in which like reference numbers denote the same element throughout.